TCP delayed acknowledgment is a technique used by some implementations of the Transmission Control Protocol in an effort to improve network performance. However, in some circumstances it can in fact reduce performance.
The socket level tries to guess what the application level is doing, in order to manage communications efficiently. Often it guesses wrong.
If the socket layer immediately acked everything, this would result in a lot of wasted acks, as usually the application sends a response shortly after receiving something, so we would be issuing two acknowledgments, one from the socket layer, one from the application layer. So the socket layer waits one or two hundred milliseconds, and if there is still nothing to send, sends an ack.
Unfortunately, the socket layer at the other end, the TCP stack at the other end, may well be waiting for an ack (see Nagle's algorithm).
If the socket layer at the other end has less than a full packet to send, well, it does not want to send unnecessarily small packets, so it waits a bit in the hope of having more data to send. It waits until it gets an ack for the data it has already sent. This can result in a brief delay.
Bob is sending stuff to Carol:
Bob's socket layer has less than a complete packet remaining to send. It will not be sent till he gets ack for the data already sent.
Carol's application layer will not send a response till it gets all the data. Carol's socket layer will not send an ack until it times out, or Carol makes a response.
If we are transmitting files in chunks of a hundred thousand bytes, over a gigabit network, all these two hundred millisecond delays can slow things down a great deal.
To prevent this delay, the application layer needs to emulate the socket layer, and keep on sending stuff without waiting for acknowledgment of the last thing it sent.